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ABSTRACT 

A local-remote telerobot system for single and 
dual-arm supervised autonomy, shared control, 
and teleoperation has been demonstrated. The 
system is composed of two distinct parts: the local 
site, where the operator resides, and the remote 
site, where the robots reside. The system could 
be further separated into dual local sites commu- 
nicating with a common remote site. This is valu- 
able for potential space missions where a space 
based robotic system may be controlled either by 
a space based operator or by a ground based op- 
erator. Also, multiple modes of control integrated 
into a common system is valuable for satisfying dif- 
ferent servicing scenarios. The remote site single 
arm control system is described and its parameter- 
ization for different supervised autonomous con- 
trol, shared control, and teleoperation tasks are 
given. Experimental results are also given for se- 
lected tasks. The tasks include compliant grasp- 
ing, orbital replacement unit changeout, bolt seat- 
ing and turning, electronics card removal and in- 
sertion, and door opening. 

I. INTRODUCTION 

Supervised autonomous control, shared con- 
trol, and teleoperation may be utilized for Space 
Station Freedom robotics applications. In teleop- 
eration, trajectory points generated by an opera- 
tor’s motion of a hand controller are continuously 
sampled and communicated to a robot to track. In 
supervised autonomous control, autonomous com- 
mands are generated and then sent for execu- 
tion on the robot. Trajectories are generated au- 
tonomously by specifying segment endpoints and 
trajectory parameters. The autonomous com- 
mands can be saved, simulated, and/or modified 


before sending them to the remote site for execu- 
tion. Shared control is the merging of autonomous 
and teleoperation control. For example, the op- 
erator could specify the trajectory with the hand 
controller and the autonomous system could con- 
trol the contact forces with the environment. 

The planned baseline telerobotics capability 
for the Space Station is teleoperation with a Space 
Station based operator. Supervised autonomous 
control and shared control could provide valuable 
additional capability. Space Station based control, 
where the operator resides on the Space Station, 
could utilize supervised autonomy, shared control, 
or teleoperation. For ground (Earth) based con- 
trol, there is expected to be an approximately 
8 second round trip time delay for commands to 
the Space Station. Laboratory experiments in- 
dicate that time-delayed ground based control of 
Space Station robots can be safely achieved using 
supervised autonomous control. With such a sys- 
tem there would be dual local sites, one on Earth 
and one on the Space Station, communicating with 
a common remote site. 

The basic architecture of the system provides 
a remote site capability with simultaneous multi- 
ple sensor based control and a local site capability 
which can generate commands and parameteriza- 
tion to send to the remote site. The Generalized 
Compliant Motion with Shared Control (GCMSC) 
[1] task primitive provides the remotes site system 
multi-sensor based control. The User Macro In- 
terface (UMI) [2, 3] provides the local site task 
description and command sequencing. The uti- 
lization of sensors, both real and virtual, enhances 
task execution capability both by providing alter- 
native approaches for executing a task and by mak- 
ing task execution more robust. A very simple 
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robotic system might have purely position control 
of a robot from a trajectory generator. Adding a 
hand controller allows the operator to perform po- 
sition teleoperation. A force-torque sensor makes 
force/compliance control possible and therefore ro- 
bust contact tasks. A virtual force field sensor can 
sud the operator during teleoperation to keep the 
robot away from joint limits and objects. 

A task execution primitive is a function which 
controls a manipulator to perform the task de- 
scribed by its input parameter set. It generates the 
desired setpoints and performs the required con- 
trol. The parameter list is the interface between 
a higher level task planning system and task exe- 
cution. The planning system only needs to know 
how to describe the desired behavior of execution 
by setting the input parameters of the task primi- 
tive. 

The paper will focus on the remote site 
GCMSC control and parameterization for specific 
tasks as well as give experimental results. The 
GCMSC primitive [1] and UMI [2, 3] have been 
described in previous publications. The paper is 
organized as follows. Section II discusses the in- 
put parameter set of the primitive and section III 
describes the control architecture. Motion control 
is described in section IV, monitoring and status 
reporting in section V, and command results in 
section VI. Section VII describes the implementa- 
tion environment and section VIII discusses spe- 
cific task parameterization .and gives experimental 
results. Section IX describes new developments 
which extend the technology. Section X gives con- 
clusions. 

II. INPUT PARAMETER SET 

The input parameter set is composed of five 
parameter types: system, trajectory, fusion, sen- 
sor, and monitor. Sensors generally have control 
and monitoring parameters. The addition of a sen- 
sor would normally require the addition of sensor 
and monitor input parameters for that sensor. The 
parameters are described throughout the remain- 
der of the paper and are printed in bold letters. 


III. CONTROL ARCHITECTURE OF 
THE PRIMITIVE 

The GCMSC primitive provides six sources of 
robot motion which can be used individually or si- 
multaneously. These sources of motion have two 
basic types: nominal motion trajectory generator 
and sensor based motion. The trajectory generator 
provides a feedforward Cartesian nominal position 
Xd of the NOM frame. Each of the sensors pro- 
vides a perturbation to the nominal position of the 
NOM frame and these are all merged at the current 
NOM frame and the result is integrated with the 
past cumulative sensor based motion. The virtual 
restoration springs motion takes the integrated cu- 
mulative sensor based motion and tries to reduce 
it. The Generalized Compliant Motion control ar- 
chitecture is similar to position based impedance 
control [4, 5, 6, 7, 8]. 

The motion is programmed using the following 
kinematic ring equation. 

trBase ■ trTn • trNom ■ trDel ■ trDrive 

= trBase • trTnDest • trNom. (1) 

The WORLD frame is a fixed coordinate frame. 
trBase is the constant transform from the 
WORLD frame to a frame fixed in the manip- 
ulator’s fixed first link, BASE. trTn is the vari- 
able transform from BASE to a frame fixed in the 
terminal link of the manipulator, TN. This trans- 
form changes each sample interval during control 
and is computed based on the results of all other 
inputs. trNom is the constant transform from 
the TN frame to the frame in which Cartesian in- 
terpolated motion will occur, NOM. trDel is the 
variable transform which has the integration of all 
sensor based motion. trDrive is the variable trans- 
form which provides Cartesian interpolated motion 
[9]. This transform is initially computed to satisfy 
the initial conditions of the transforms in the ring 
equation and is interpolated to the identity trans- 
form at the end of the nominal motion. trTnDest 
is the constant transform used to specify the nom- 
inal destination of the TN frame (is the expected 
value of the trTn transform at the end of nominal 
motion). At each sample interval, the trajectory 
generator calculates trDrive , sensor based motion 
calculates trDel, and then trTn is computed by 
solving equation 1. Inverse kinematics computes 
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the joint angles equivalent to trT n and the robot 
controller servos the manipulator to these joint an- 
gles. 

Most of the sources of input can specify their 
inputs in a coordinate frame specific to their func- 
tionality; nominal motion in NOM, teleoperation 
in TELEOP, force control in FORCE, etc. This is 
useful because the inputs may be most effectively 
specified in separate frames. For example, see the 
door opening task in Section VIII. 

There are two time segments of motion dur- 
ing the execution of GCMSC: the nominal motion 
segment and the ending motion segment. When 
the primitive starts, it executes the nominal mo- 
tion segment with the specified Cartesian interpo- 
lated motion and all other sensors. Motion stops 
if a monitor event is triggered or Cartesian in- 
terpolated motion completes. If the nominal mo- 
tion segment completes normally, then the end mo- 
tion segment begins. Exactly the same control oc- 
curs except there is no Cartesian interpolated mo- 
tion; only the sensor based motion is active. But, 
whereas during the nominal motion segment the 
termination conditions were not being tested, they 
are tested during the ending motion and the mo- 
tion can stop on a monitor event, time, or a ter- 
mination condition. The ending motion is needed 
after the nominal motion segment to relax forces 
built up due to the nominal motion. Also, testing 
for ending conditions may not be desired until the 
nominal task is complete. 

IV. MOTION CONTROL 

The general architecture for control in 
GCMSC has been described above. The control 
for the individual inputs will be described in this 
section. 

FV.A. Trajectory Generator 

Trajectory generation is done utilizing the 
RCCL [10] trajectory generator. The trDrive 
transform is initially given by 

trDrive = (trT nl nit • trNom ) -1 • 

trTnDest • trNom (2) 


tial value to the identity transform at the end of 
the motion. The interpolation is controlled by the 
input parameters timeVelSel, timeVelVal, and 
accTime. timeVelSel selects whether to finish 
the motion in a specified time or with a specified 
velocity. timeVelVal is the time or velocity to ex- 
ecute the motion in. accTime is the time to ramp 
up to maximum velocity. 

IV.B. Force Control 

Force control is implemented independently in 
each degree of freedom of the Cartesian force con- 
trol frame FORCE. The control modifies the po- 
sition setpoint to control the forces [11, 12]. The 
result of force control each sample interval is the 
perturbation transform trDelFc. The first step 
of force control during a sample interval is the 
projection of forces 1 from the force-torque sensor 
frame to the SENSE frame (trSense is the trans- 
form from the NOM frame to the SENSE frame). 
A 6 DOF wrist force-torque sensor supplies forces 
and torques along and about the axes of the SEN- 
SOR frame centered in the force sensor. These are 
then projected to equivalent forces in the TN frame 
using rigid body force transformations. The load 
(the complete composite body beyond the force 
sensor) forces due to gravity are then computed. 
The mass and center of mass of the load with re- 
spect to the TN frame are given in the massProp 
input parameter. The current TN frame orientar 
tion with respect to the gravity vector is used with 
the load mass properties to determine the grav- 
ity load forces in the TN frame. These are then 
subtracted from the total sensed forces in the TN 
frame. The resulting forces and torques are those 
due only to contact and are then projected to the 
SENSE frame. The forces in the SENSE frame are 
then passed through a filter which reduces their 
magnitude by the values in the input vector pa- 
rameter deadZone (if one of the force magnitudes 
is initially less than the deadZone value, then it is 
set to zero). The deadZone filter is useful to reduce 
drift due to inaccuracies in the mass properties of 
the load. 

Force control is calculated in the FORCE 
frame using the forces projected into the SENSE 


where trTnlnit is the initial value of trTn. 1 in this paper the term forces generally implies & 6 vector 
trDrive is then linearly interpolated from this ini- of both forces and torques 
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frame. (trForce is the transform from the NOM 
frame to the FORCE frame). The FORCE and 
SENSE frames will usually coincide but there are 
cases where they may be different, such as leveling 
a plate on a surface where the SENSE frame is at 
the center of the plate and the FORCE frame is at 
the point of contact. If the SENSE and FORCE 
frames were both at the point of contact, then no 
moments would be felt and therefore no rotation 
due to force control would occur since the force line 
of action would be through the control frame. 

The selVectFc selection vector selects which 
of the 6 DOF of the FORCE frame are to have force 
control. In these degrees of freedom, the contact 
forces which were projected from the TN frame to 
the SENSE frame are subtracted from the six set- 
points in the forceSetpoints vector input param- 
eter. The resulting force errors are then multiplied 
by the constants in the forceGains vector input 
parameter to produce a differential motion vector 
of six perturbations in the FORCE frame, three 
translations and three rotations given by 

dj = (d^ x , djy, dj x , 6f x , f>fy, fi/z) (3) 

The magnitudes of the elements of the dj vector 
are then limited. The maximum magnitudes of 
the dj perturbations per sample interval are the 
velocity limits given in the maxForceVel input 
parameter multiplied by the sample interval. 

The F0RCE trDelFc transform is a differential 
translation and rotation transform with elements 
given by dj [9]. The trDelFc transform is then 
transformed to the NOM frame. trDelFc with re- 
spect to the FORCE and NOM frame are related 
by the following equation. 

NOM trDelFc • trForce = trForce 

FORCE trDelFc (4) 

The trDel transform of equation 1 is then updated 
with the perturbation due to force control with 

trDel = NOM trDelFc • trDel (5) 

Premultiplication is required rather than postmul- 
tiplication because the motion is with respect to 
the NOM frame. 

IV.C. Dither Sensor Control 

Dither signals can be used to perturb the mo- 
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tion independently in each degree of freedom of 
the DITHER frame. Presently only a triangu- 
lar waveform is available although other waveforms 
will be implemented such as sinusoidal and square. 
Dither is useful to overcome stiction, e.g., when 
pulling a pin out of a hole. The magnitude and 
period of the dither waveforms for each DOF of 
the DITHER frame are given in the input parame- 
ters ditherMag and ditherPeriod. As with force 
control, the inputs in each degree of freedom are 
elements of a differential translation and rotation 
transform, trDelDt which is transformed to the 
NOM frame in the same manner as for trDelFc. 
The trDel transform then updated with the per- 
turbation due to the dither waveforms with 

trDel = NOM trDelDt ■ trDel (6) 

IV.D. Teleoperation Sensor Control 

The teleoperation sensor is actually a 6 DOF 
hand controller. Each sample interval the change 
in joint angles of the hand controller are read 
and put in a differential vector. This vector is 
multiplied by the hand controller Jacobian to get 
the input Cartesian motion perturbations. The 
appropriate Jacobian is used depending on the 
teleMode parameter to compute the Cartesian 
motion with respect the the hand controller grip 
which would be tool mode teleoperation, or with 
respect to a frame fixed with respect to the hand 
controller base, which would be used for world or 
camera mode teleoperation. These perturbations 
are then transformed to the TELEOP frame which 
is given with respect to the NOM frame by the 
input parameter trTeleop. Again, the mode de- 
termines how the perturbations are transformed 
to the TELEOP frame. trCamera is used for 
camera mode teleop to specify the present oper- 
ator viewing orientation. The details of the var- 
ious modes of teleoperation are explained in [13]. 
The selVectTp selection vector selects which de- 
grees of freedom of teleoperation inputs to include 
and teleGains are weightings for the inputs. The 
maxTelVel limits the rate of teleoperation inputs. 

Force reflection is also available in the system. 
The robot contact forces are sent to the hand con- 
troller where they are reflected to forces felt by the 
operator at the hand grip. Force reflection was not 
used during the tasks in Section VIII. 



IV.E. Joint Sensor Control 

The joint sensor control provides joint limit- 
ing. This prevents the arm from going into a joint 
limit or singularity. Joint angle perturbations for 
all the joints are computed and put into a differen- 
tial vector. A joint angle perturbation is computed 
with 

A0 = K e (0 actual - 6 limit )-' (7) 

where Kg is the gain, 0 actual is the actual joint 
angle, and 0u m it is the limit that the joint is ap- 
proaching, either as a joint limit or singularity. 
The differential vector is multiplied by the Jaco- 
bian to get the required Cartesian motion. This is 
transformed to the NOM frame and added to trDel 
as is the case with the other previous sensors. 

IV.F. Virtual Restoration Springs Control 

The virtual restoration springs act on the 
trDel transform to pull it towards the identity 
transform. This reduces the accumulated motion 
due to sensory inputs and causes the actual mo- 
tion to approach the nominal motion. Virtual 
springs are applied in the DOFs specified by the 
selVectSp input parameter. Four virtual springs 
are used, one along each translational degree of 
freedom and one orientational spring. For the 
translational DOFs, the spring lengths are equal to 
the displacement vector, p, elements of the trDel 
transform ( trDel is a homogeneous transform with 
column vectors n, d, a, and p). The transla- 
tional perturbations due to the virtual springs, 
d sy are then the spring lengths multiplied by the 
translational spring gains in the springGains vec- 
tor, k s , input paramter, i.e., d, x = -k tx p x , 
d 9 y — kgyPyi and d zz — k sz p z . 

Virtual springs for orientation is applied 
about one axis with respect to the NOM frame. 
The selection of this axis depends upon the num- 
ber of orientation degrees of freedom specified in 
selVectSp. The axis is u and the angular dis- 
placement about this axis is 0. If all orientation 
DOFs are selected, then ti is the equivalent axis 
of rotation of the trDel transform and 0 is the 
equivalent angle about the axis. If no orienta- 
tion DOFs are selected, then no orientation per- 
turbation is applied due to virtual springs. If only 
one orientation DOF is selected, then the corre- 
sponding axis x, y , or z is aligned by the orier- 
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tation virtual spring, ti and 0 are selected such 
that a rotation about ti by 0 will align the selected 
axis. The virtual springs orientation perturbation 
is then 6 t g = —k t g0. The four virtual springs per- 
turbation magnitudes are then limited to the mag- 
nitudes given in the maxSpringVel vector input 
parameter as the force control perturbations were 
limited by the maxForceVel values. The trDel 
transform is then updated with the perturbations 
due to virtual springs with 

trDel = trans(x,d tx ) • trans(y } d sv ) • 

trans(z,d , z ) • rot(u,£, fl ) • trDel (8) 

where trans(v,d) is a translation of d along the 
v axis and rot(v,6) is a rotation of 6 about the v 
axis. 

V. MONITORS 

Various parameters are continuously moni- 
tored during execution. The magnitudes of the 
translational part of trDel and the equivalent ro- 
tation of the orientational part of trDel are com- 
pared against the input parameters posThresh- 
old and orientThreshold. If the values grow 
larger than the thresholds, then the motion stops. 
Also, the vector magnitudes of the contact forces 
and torques in the FORCE frame are compared 
against forceThreshold and torqueThreshold 
and motion stops if one of them is larger than the 
threshold. If the distance to a joint limit or singu- 
larity is less than the angles in the jSafetyLimit 
input vector, then motion stops. 

Anther monitor is the termination condition 
monitor. It is used during the end motion (see 
section III). The end motion continues until all of 
the specified termination conditions are satisfied or 
until the time limit given by the endTime input 
parameter is passed. The select input parame- 
ter is a bit mask which selects which termination 
conditions to test for. Any combination of ter- 
mination conditions can be tested. All termina- 
tion conditions relate to forces and torques in the 
SENSE frame or sensor based motion specified by 
the trDel transform. Each termination condition 
is calculated as a moving average of data sampled 
each 200 ms over a window of testTime ms. Sat- 
isfaction of a termination condition means that its 
magnitude is less than its associated input parame- 
ter limit. The endTransErr condition is the mag- 


nitude of the trDel transform p vector including 
only the position degree of freedom components. 
The endAngErr condition is the magnitude of the 
virtual restoration springs angular displacement, 9 , 
described above. The endTransVel and endAn- 
gVel parameters are the rate of change of the end- 
TransErr and endAngErr conditions. The end- 
ForceErr and endlbrqueErr parameters are the 
magnitudes of the force and torque error vectors 
in the SENSE frame including only the force con- 
trolled degrees of freedom. The endForceVel and 
endTorqueVel parameters are the rate of change 
of the endForceErr and endTorqueErr condi- 
tions. 

During execution of the primitive, the system 
executive reports the status of execution to the 
local site system. The report includes information 
such as contact forces and joint angles. 

VI. COMMAND RESULTS 

Various possible causes for the motion to stop 
have been described above. When the motion 
stops, the cause is returned to the local site system 
along with the system status. Each possible cause 
of motion termination has a unique command re- 
sult code. 

VII. IMPLEMENTATION 
ENVIRONMENT 

The remote site with the GCMSC primitive 
and the local site with UM1 are operational in 
the JPL Supervisory Telerobotics (STELER) Lab- 
oratory running PUMA 560 manipulators with six 
DOF wrist force-torque sensors and servoed grip- 
pers. The GCMSC primitive was written in the 
C programming language using utilities from the 
robot control C library (RCCL) [10]. The manip- 
ulator control is multiple rate with the Cartesian 
level control of the GCMSC primitive at a different 
rate from the joint level servo control. Presently 
the Cartesian level control (all control associated 
with the GCMSC primitive including trajectory 
generator and sensor based motion) runs with a 
10 ms sample interval and the joint servo control 
has a 1 ms sample interval. Details on the hard- 
ware configuration of the system can be found in 
[14]. 


VIII. RESULTS 

Various tasks have been executed in the JPL 
STELER lab utilizing the User Macro Interface for 
task description and sequencing and Generalized 
Compliant Motion with Shared Control for task ex- 
ecution. These tasks include compliant grasp, or- 
bital replacement unit removal and insertion, bolt 
seating and turning, electronics card removal and 
insertion, and door opening. The different tasks 
utilized different combinations of the six sources of 
motion. For each task below, only the mentioned 
motion sources were used. All distance units used 
below are mm, forces are Newtons (N), and torques 
are N-mm. The forceGains input vector transla- 
tion gains units are mm/N and orientation gains 
units are deg/N-mm. The maxForceVel vector 
has translation units of mm/sec and orientation 
units of deg/sec. The springGains input vector 
has three translational gains with units mm/mm 
and an orientation gain with units deg/deg. 

The compliant grasp task utilized force con- 
trol to both level the grippers on the grapple lug 
and to adjust the position of the robot as the fin- 
gers closed. The trForce transform was selected 
so the FORCE frame was between the robot fin- 
gers. The forceSetpoints input vector was all ze- 
roes except for a force of -10 N along Z. The force- 
Gains input vector was (0.02, 0.02, 0.02, 0.00003, 
0.00003, 0.00003). The compliant ungrasp task 
opened the gripper while using force control to null 
out contact forces and virtual springs to make sure 
the gripper would not drift. The forceSetpoints 
input vector was all zeroes. The forceGains in- 
put vector was the same as for the compliant grasp 
task. The springGains input vector was (0.007, 
0.007, 0.007, 0.015). 

The orbital replacement unit (ORU) removal 
task utilized force control to pull the ORU and 
attached pin out of the passive connector. The 
arm carrying the ORU is shown in figure 1. The 
massProp inputs were 4.87 kg at position vec- 
tor (in mm) (-90.3, -4.5, 336.6) relative to the T6 
frame. The trForce transform was a translation of 
400 mm along the T6 Z axis. The forceSetpoints 
input vector was all zeroes except for a force of 
15 N along Z. The forceGains input vector was 
(0.02, 0.02, 0.02, 0.00001, 0.00001, 0.00001). The 
maxForceVel input vector was (30, 30, 30, 5, 
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Figure 2: ORU removal task: solid is force along 
Figure 1: Manipulator carrying ORU FORCE Z; dashed is translation along FORCE Z 


5, 5). Figure 2 shows the force and displace- 
ment along the FORCE frame Z axis during the 
task. The figure shows that the maxForceVel of 
30 mm/sec limited the velocity due to force con- 
trol to 30 mm/sec so that the force could not reach 
its setpoint. The motion stopped on the position 
monitor with posThreshold input parameter of 
160 mm. 

The ORU insertion task used the same param- 
eters as the oru removal task except that the task 
completed on the time monitor and the force set- 
point along Z was -15 N. Figure 3 shows the force 
and displacement along the FORCE frame Z axis 
during the task. 

The bolt seating task utilized Camera mode 
shared control teleopertion. The teleMode pa- 
rameter specified Camera mode teleoperation. The 
trTeleop transform put the TELEOP frame on 
the socket shaft. The forceGains input vector 
was (0.03, 0.03, 0.03, 0.00003, 0.00003, 0.00003). 

The bolt unscrew task used force control to 
cause the bolt to turn. The trForce transform was 
selected so that the FORCE frame was above the 
socket. The forceSetpoints input vector was (0, 
0, -5, 0, 0, 6000). The forceGains input vector 
( 0 . 01 , 0 . 01 , 0 . 01 , 0 . 00001 , 0 . 00001 , 0 . 00001 ). 
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Figure 3: ORU insertion task: solid is force along 
FORCE Z; dashed is translation along FORCE Z 
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Figure 4: Electronics card insertion and removal 


The -5 N force kept the socket on the bolt. The 
6000 N-mm torque caused the bolt rotation. The 
orientThreshold input parameter of 90 degrees 
caused the task to terminate after the bolt rotated 
90 degrees. The bolt screw task was the same ex- 
cept that a torque of -6000N-mm was used to screw 
the bolt on. The task terminate either on the ori- 
entThreshold of 90 degrees or on time if the bolt 
would not turn any more. 

Four tasks were used for electronics card in- 
sertion and removal, as shown in figure 4. A real 
electronics card and chassis were used in the ex- 
periment. The first task was camera mode shared 
control teleoperation where the operator used the 
hand controller to partially insert the card into the 
card slot. The operator at the local site opera- 
tor control station is shown in figure 5. Camera 
mode teleoperation caused the robot to move in 
the same direction relative to the cameras mounted 
on the camera arm (see figure 1) as the operator’s 
hand moved relative to the stereo display moni- 
tor. Force control with zero setpoints was used to 
null out the contact forces between the card and 
the slot. The teleMode parameter specified Cam- 
era mode teleoperation. The trTeleop transform 
put the TELEOP frame on the electronics card. 
The forceGains input vector was (0.03, 0.03, 0. 03, 
0.00003, 0.00003, 0.00003). 727 



Figure 5: Operator at local site OCS 


Once the electronics card was successfully 
placed in the chassis slot, autonomous commands 
were used to slide the card to the backplane and 
seat it in the backplane. Sliding the card to 
the backplane was done using force control. The 
forceSetpoints input vector was (0, 0, -15, 0, 0, 0) 
and the forceGains input vector was (0.01, 0.01, 
0.01, 0.00001, 0.00001, 0.00001). Figure 6 shows 
the translation and forces along the FORCE frame 
Z axis. A larger force is needed to seat the card in 
the backplane than was used to slide the card to 
the backplane. To seat the card in the backplane, 
the force along the FORCE Z axis was set to -60N 
and the same forceGains were used. The results 
are shown in figure 7. Unseating the electronics 
card from the backplane is achieved by applying 
a force of 60 N along the FORCE frame Z axis. 
After the card breaks free of the backplane, a ve- 
locity limiting filter limits the velocity using the 
maxForceVel input parameters (2.5, 2.5, 2.5, 3, 
3, 3). The results are shown in figure 8. 

Shared control was used for the dome cleaning 
task as shown in figure 9. A trTeleop transform 
of 290 mm along T6 Z was selected so that the 
TELEOP frame was in the middle of the pad. The 
operator was given three hand controller degrees of 
freedom of input - two tangential to the dome sur- 
face and one about the surface normal as specified 
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Figure 6: Electronics card sliding to the backplane; 
solid is force along FORCE Z; dashed is translation 
along FORCE Z 



Figure 7: Electronics card seating in backplane: 
solid is force along FORCE Z; dashed is translation 
along FORCE Z 
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Figure 8: Electronics card unseating from back- 
plane: solid is force along FORCE Z; dashed is 
translation along FORCE Z 



Figure 9: Dome cleaning task 


in the selVectTp input vector (1, 1, 0, 0, 0, 1). 
The FORCE frame was the same as the TELEOP 
frame. The forceSetpoints input vector was (0, 
0, -20, 0, 0, 0) and the forceGains input vector 
was (0.02, 0.02, 0.02, 0.00012, 0.00012, 0.00002). 
The 20 N force caused the pad to stay in contact 
with the curved surface. When the pad was moved 
so that the FORCE frame was not at the point of 
contact, then the 20 N would generate a moment 
and the pad would automatically rotate until the 
FORCE frame was again at the contact point. In 
this way, the operator could polish the dome sur- 
face but could not cause motion with the hand 
controller which would cause damage to the sur- 
face. 


The last task is the door opening task which 
was done with both shared control teleoperation 
and autonomous control. The door task is shown 
in figure 10. For the door opening with teleoper- 
ation task, the trTeleop input transform was se- 
lected so that the TELEOP frame Z axis was along 
the hinge axis. The trForce input transform placed 
the FORCE frame at the knob where the robot 
was grasping the door. The forceSetpoints in- 
put vector was all zeros and the forceGains input 
vector was (0.015, 0.015, 0.015, 0.00002, 0.00002, 
0.00002). The operator opened and closed the door 
simply by a one DOF rotation of the hand con- 
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Figure 11: Autonomous door opening results: solid 
Figure 10: Door opening task is motion of FORCE frame; dashed is rotation of 


NOM frame (hinge axis) 

troller grip. 


For the door opening with autonomous con- 
trol task, the autonomous trajectory generator was 
used instead of teleoperation inputs to cause the 
nominal motion. The trNom input transform 
placed the NOM frame such that its Z axis was 
along the door hinge axis. The forceSetpoints 
and forceGains input vectors were the same as 
for the compliant teleoperation case above. Vir- 
tual springs were necessary so that the motion due 
to force control would not cause the actual mo- 
tion to drift far from the reference nominal trajec- 
tory. The springGains input vector was set to 
(0.007 0.007 0.007 0.015). The select termination 
condition input was set to select the endAngErr 
as the termination condition to monitor; endAn- 
gErr was set to 0.1 deg. A relative autonomous 
motion was specified to rotate the NOM frame by 
30 degrees. The results are shown in figures 11 and 
12. The figures show that the door was success- 
fully opened 30 degrees. 

The value of the virtual springs is shown by 
executing the same task but with the spring- 
Gains input vector elements set to zero. The re- 
sults are shown in figure 13. In this case the door 
opened a maximum of only 21.6 deg. The maxi- 
mum rotation occurred when the trajectory gener- 
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Figure 12: Autonomous door opening results: 

forces along FORCE frame X (□), Y(O), and 
Z(A) axes 
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Figure 13: Autonomous door opening results (no 
virtual springs): solid is motion of FORCE frame^ 
dashed is rotation of NOM frame (hinge axis) 
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Figure 14: Autonomous door closing: solid is mo- 
tion of FORCE frame; dashed is rotation of NOM 
frame (hinge axis) 


ator finished. After that, the ending motion time 
segment began and the door slowly began closing 
due to its gravity weight. The ending condition of 
0.1 deg. from the 30 deg. goal was never satisfied 
so it stopped on the endTime timeout. The rear 
son that the door did not open all of the way is that 
the forces in the FORCE frame caused compliant 
motion to resist the nominal trajectory generator 
motion and there were no virtual springs to offset 
this motion. 

The door opening task was followed by a door 
closing task. The same parameters as for the 
door opening task were used, including virtual 
springs, except that the nominal motion was neg- 
ative 32 deg. and different termination conditions 
were used. A 32 deg. motion was used to be sure 
to have at least the 30 deg. of motion needed. 
The select termination condition input was set to 
select the endTransVel and endAngVel as the 
termination conditions to monitor; endTransVel 
was set to 1 mm/sec and endAngVel was set to 
0.1 deg/sec. The results are shown in figures 14 
and 15. The figures show that the door was suc- 
cessfully closed 30 degrees. The motion is nearly 
linear until the door makes contact and is closed 
at 30 deg. Then the rotation stops which triggers 
the termination condition. 



Figure 15: Autonomous door closing results: forces 
along FORCE frame X (□), Y(Q), and Z(A) axes 





IX. DUAL- ARM AND IMPEDANCE 
BASED REDUNDANT ARM CONTROL 

The GCMSC primitive has been generalized 
for dual- arm cooperative control teleoperation, su- 
pervised autonomy, and shared control with the 
Dual- Arm Generalized Compliant Motion primi- 
tive [15]. It was then generalized for impedance 
based control of a six DOF manipulator [13] and 
then impedance based control of a redundant seven 
DOF manipulator [16]. 

X. CONCLUSIONS 

A local- remote control system with unified au- 
tonomous control, shared control, and teleopera- 
tion has been described. The local site generates 
teleoperation and autonomous commands which 
are communicated to the remote site. The remote 
site uses a parameterized task primitive to execute 
tasks. The execution of various tasks in the labo- 
ratory demonstrates the capability of the system. 
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